REMARKS 

The present remarks are in response to the Office Action dated 
September 6, 2005. Claims 1-32 are now pending in this case. No claims have been 
amended in the present response. However, all claims are included herewith for the 
Examiner's convenience. 

The applicants wish to express their appreciation to the Examiner for the 
withdrawal of finality of the prior Office Action. The applicants further wish to express 
their appreciation to the Examiner for the Examiner's indication that claims 4-10 and 14- 
21 contain allowable subject matter and would be allowable if rewritten in independent 
form. However, as discussed below, the claims are believed allowable in their present 
form. 

Claims 1-3, 11-13, and 22-32 stand rejected under 35 U.S.C. § 102(a) as 
anticipated by a non-patent publication by Makam et al. The applicants respectfully 
request removal of Makam as a reference. The present application claims priority from 
U.S. Application No. 09/395.831 , filed on September 14, 1999. This predates the 
November 2000 publication date of Makam. 

In a previous Office Action, it was asserted that the priority document did 
not support the claimed invention. However, a careful reading of that priority document 
discloses full support for the method recited, by way of example, in claim 1 . U.S. 
Application No. 09/395,831 describes protection switching in an asynchronous transfer 
mode (ATM) network. As described on page 10 of the priority document, "Protection 
switching is a process where an alternate path (protection path) is provided in addition 
to the path in use, whenever an impairment is detected on the path is (sic) use (working 
path)." (See Application No. 09/395,831, page 10, lines 19-20.) One skilled in the art 
will appreciate that a computer network inherently involves communication between 
network nodes. Thus, the priority document clearly describes the step of establishing a 
working network path and a protection network path between first and second nodes. 

The priority document further recites switching traffic from the working 
network path to the protection network path when traffic congestion is detected in the 
working network path that exceeds a predetermined threshold. (See Application 
No. 09/395,831, Figure 6 and page 15, lines 5-11.) 
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Thus, claim 1 of the present application is entirely supported by the 
disclosure in the priority document with the exception of the implementation in a virtual 
private network. To the extent that a VPN is inherent in the MLPS, as asserted in the 
Office Action, a VPN network is also inherent in an ATM protocol. One skilled in the art 
would realize that the teachings in the priority document would be applicable to a VPN. 
This position is further supported by a definition of a virtual private network which is a 
wide area network "fomned of permanent virtual circuits (PVCs) on another network, 
especially a network using technologies such as ATM or frame relay." Microsoft 
Computer Dictionary. 5th ed.. Microsoft Press, Redmond. Washington. © 2002, 
Microsoft Corporation. Thus, one skilled in the art relying on the priority document 
would find full support for claim 1 of the present application. Therefore, the priority 
document provides support for the claimed invention. Accordingly. Makam should be 
removed as a reference. 

Even if one carefully considers the teachings of Makam, the reference 
does not teach or even suggest the claimed invention. The Office Action states that 
Makam discloses protection switching in a MPLS network and asserts that VPN is 
inherent in the MPLS network of Figure 1 . The Office Action further asserts that Makam 
discloses establishing a working network path and a protection network path between 
first and second nodes and switching traffic from the working network path to the 
protection network path when traffic congestion is detected in the working network path 
that exceeds a predetermined threshold. This is incorrect. 

First, the Office Action asserts that a VPN network is inherent in an MPLS 
network. To that extent, a VPN network is also inherent in the ATM network described 
in U.S. Application No. 09/395,831 . from which priority is claimed in the present 
application. As noted above, the priority document provides detailed description of a 
working network path and a protection network path and switching traffic from the 
working network path to the protection path in the event of congestion. 

Furthermore, Makam is directed to a protection pathway in the event of a 
communication failure. Examples of detected failures are provided on page 5 of 
Makam. It is important to note that traffic congestion is not considered to be a failure 
condition in Makam. The thresholds noted in the Office Action and discussed in Makam 
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on page 12 relate to time out periods related to the network failure modes, but is 
unrelated to any traffic congestion threshold measurement. Thus, nothing in Makam 
suggests any equivalence between traffic congestion and network failure. However, 
such equivalence is stated in the priority document, U.S. Application No. 09/395.831. 
The method described in that document "treats the onset of congestion in a network as 
a soft failure of the network entity where it occurs." (See Application No. 09/395,831 . 
page 10. lines 20-22.) Thus, claim 1 is allowable for at least two reasons. First, the 
priority document, which predates Makam, provides full support for the recited method. 
Second. Makam does not address traffic congestion and thus fails to anticipate, or even 
suggest the method of claim 1 . For at least these reasons, claim 1 is clearly allowable 
over Makam. Claims 2-1 1 are also allowable in view of the fact that they depend from 
claim 1 , and further in view of the recitation in each of those claims. 

Claim 12 is an apparatus claim for a VPN having a working VPN path and 
a protection VPN path. Claims 12 recites inter alia a congestion detector "configured to 
detect traffic congestion on said working virtual network path and said data switch 
switches said data from said working virtual network path to said protection virtual 
network path when said traffic congestion exceeds a predetermined threshold." As 
discussed above with respect to claim 1 , Makam does not teach or suggest any 
mechanism for detecting traffic congestion. The Office Action, at page 4, asserts that a 
congestion detector is inherent as a fault detection mechanism. However, Makam 
discusses network failures and does not suggest traffic congestion as a form of a 
network failure. Furthermore, Makam explicitly states that "fault detection is outside the 
scope of this draft." (See Makam, page 5.) Thus, Makam does not address traffic 
congestion, or suggest any stmcture that functions as a congestion detector, such as 
recited in claim 12. Finally, claim 12 is supported by the priority document. The 
working network path and protection network path are explicitly disclosed in Application 
No. 09/395,831, as described above. A switch is also explicitly disclosed (see Figure 7) 
as is the operation of a congestion detector. Thus, all elements of claim 12 are 
disclosed in the priority document except implementation in a VPN. Those skilled in the 
art would recognize that the teachings of the priority document can be readily applied to 
a VPN. Accordingly, claim 12 is clearly allowable over Makam. Claims 13-23 are also 
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allowable in view of the fact that they depend from claim 12, and further in view of the 
recitation in each of those claims. 

Claim 24 is an apparatus claim that recites inter alia "a monitor module 
configured to monitor the virtual private network path to monitor traffic flow thereon, the 
monitor module configured to cause a switch in traffic from the working virtual private 
network path to the protection virtual private network path in response to a detected 
event selected from a group of events comprising congestion in the working virtual 
private network path that exceeds a predetemriined threshold and link failure in the 
working virtual private network path." As discussed above with respect to claims 1 and 
12. nothing in Makam deals with network failure and does not suggest the detection of 
traffic congestion on the working virtual private network path that exceeds a 
predetermined threshold. Furthermore, the monitor function in a computer network 
having a working network path and a protection network path is explicitly disclosed in 
the priority document. For these reasons, among others, claim 24 is cleariy allowable 
over Makam. Claims 25-28 are also allowable in view of the fact that they depend from 
claim 24, and further in view of the recitation in each of those claims. 

Claim 29 is directed to a virtual private network having a router/switch and 
reciting inter alia "a monitor module configured to monitor the working virtual private 
network path to monitor traffic flow thereon, the monitor module configured to cause the 
router/switch to switch traffic from the working virtual private network path to the 
protection virtual private network path in response to a detected event selected from a 
group of events comprising congestion in the working virtual private network path that 
exceeds a predetermined threshold and link failure in the working virtual private network 
path." As discussed above, Makam does not teach or suggest any structural element 
equivalent to the monitor module recited in claim 29. Specifically, Makam does not 
monitor traffic flow and cause the router/switch to switch traffic in the event of 
congestion in the working virtual private network path that exceeds a predetermined 
threshold, as recited in claim 29. Furthermore, the monitor function in a computer 
network having a working network path and a protection network path is explicitly 
disclosed in the priority document. For these reasons, among others, claim 29 is cleariy 
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allowable over Makam. Claims 30-32 are also allowable in view of the fact that they 
depend from claim 29. and further in view of the recitation in each of those claims. 

In view of the above remarks, reconsideration of the subject application 
and its allowance are kindly requested. The applicants have made a good faith effort to 
place all claims in condition for allowance. If questions remain regarding the present 
application, the Examiner is invited to contact the undersigned at (206) 628-7640. 



MJD:gatc 

2600 Century Square 

1501 Fourth Avenue 

Seattle, Washington 98101-1688 

Phone: (206)622-3150 

Fax: (206)628-7699 

1689984 1. DOC 67742-13 



Respectfully submitted, 
Davis Wright Tremaine llp 
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